Skip to content

fix: send mDNS queries from multicast sockets - #167

Open
BetterAndBetterII wants to merge 1 commit into
hashicorp:mainfrom
BetterAndBetterII:fix/sendquery-multicast
Open

BetterAndBetterII wants to merge 1 commit into
hashicorp:mainfrom
BetterAndBetterII:fix/sendquery-multicast

Conversation

@BetterAndBetterII

Copy link
Copy Markdown

Description

sendQuery sent mDNS queries to the multicast destination (224.0.0.251 / ff02::fb) from ephemeral unicast sockets. Some devices only answer queries that originate on a multicast socket bound to UDP port 5353 (RFC 6762).

This change writes queries from ipv4MulticastConn / ipv6MulticastConn instead, and enables multicast loopback on those sockets so same-host discovery (Lookup / local server) still works.

Related Issue

Fixes #144

How Has This Been Tested?

go test -count=1 -timeout=60s ./...

Includes a new regression test (TestSendQuery_UsesMulticastSocket) that closes the unicast socket and asserts the query still arrives from the multicast socket's source port. Existing TestServer_Lookup continues to pass with multicast loopback enabled.

Contributor Checklist

  • LLM Usage If an LLM was used to generate any code, please ensure and confirm you have read
    and followed the AI usage guide.

sendQuery wrote to the multicast destination from ephemeral unicast
sockets. Some devices ignore those queries. Write from the multicast
sockets (UDP source port 5353) instead, and enable multicast loopback
so same-host discovery still works.

Fixes hashicorp#144
@BetterAndBetterII
BetterAndBetterII requested review from a team as code owners September 4, 2026 23:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

mDNS queries sent via unicast connection instead of multicast - causes discovery failures for certain devices

1 participant